Ham Radio 2000/Ham Radio 2000.iso/ham2000/tcp_ip/rose_nos/rosenet.doc

Text File | 1992-02-26 | 11KB | 247 lines

2/26/92

Preliminary notes -- Using TCP/IP with a ROSE circuit

(These are notes that accompany a pre-release NET version for those of
you who feel adventuresome.  It is K5JB version k05, or later.)

This version of NET has a work-around that permits NET to send IP frames
over ROSE circuits.  Normally, the ROSE system replaces the protocol
identifier (PID) in AX.25 information frames with its own when handling
packets between switches and does not preserve the PID from the original
user's packet's header.  In its native datagram mode NET communicates
with other NET or NOS stations using un-numbered information frames (UI)
but can be made to run in a virtual circuit mode (VC, or connected) if
necessary.  Although we can initiate VC for our transport mechanism, we
can't recognize the IP PID if it isn't there!  There are rumors that the
next version of ROSE is supposed to cure this problem, but in the mean
time I needed to use ROSE, (after all IP is an INTERNET PROTOCOL, eh?
Ah, well, bad joke!).  Besides, I can control how NET works because I
have control of the keyboard!

Two things have to be done to use ROSE circuits: 1. Trap incoming IP
frames and modify them, 2. Use virtual circuit (VC or Connected) mode on
outgoing IP frames.

The scheme I used a kludge, but it seems to work OK.  First I use
a trap that would catch suspected incoming rose information frames and
put the IP protocol identifier (PID) back.  This trap works good, and
when modified for NOS's structures, also works in NOS.  To use ROSE for
outgoing IP frames, you have to go VC mode.  Although you can use the
mode command to make an interface use VC for all outgoing traffic, if
you do you will forgo the datagram mode which has better performance
than VC.  (I didn't mean to say that; it slipped out!  Actually the
protocol performance differences are insignificant when your baselines
are really pitiful RF paths.)

For outgoing frames, to prevent having to dedicate the async port to the
VC mode, I added a command so you can attach a pseudo interface which
has most of the attributes of an already attached asynchronous inter-
face.  You then use that pseudo interface to specify that you want to
use virtual circuit.  This way, not all transactions that start from
that async port need to be VC.

(I am not through evaluating the scheme and looking for side effects.
If you experience problems caused by the pseudo interface, simply set
your async port mode to VC.  I have not yet found any fatal problems
with the pseudo interface.)

NOS has a different way of handling routes for outgoing packets and you
can use specify the route mode to be vc for the outgoing AX.25 route you
will be using.  Though I put the ROSE trap in the version of NOS that I
had (PA0GRI v1.7j) I didn't run it.  It was tested by N5OWK to my satis-
faction.  I normally don't use NOS so most of these instructions are for
NET.  I chose not to do routing the same way in NET as is done in NOS
because I am trying to keep NET small as practical.  Adding the trap,
etc. cost me 488 bytes -- Ouch!

First to address received packets...

You use the rose add command to create a table of distant IP stations
and associated ROSE switches that will be feeding packets to you.  This
table is used to catch incoming information frames from those stations
and put the IP PID back so NET will handle them internally.  Syntax for
this command is:

        rose add <IP station's call> <ROSE switch's call>

The distant IP station's call is the AX.25 call, not his host name. Your
neighbor ROSE switch's call is its AX.25 call.

For an example of calls used, I will describe a test circuit I used.
K5JB-10 is my IP station number 1 (host is k5jb), with N0ELS-5 as a
neighbor ROSE (address 405771).  It will be using async port kp0a which
is connected to a Kantronics KPC-4 using logical port a.  K5JB-11 is my
IP station number 2 (k5jbspook) on another frequency with K5JB-5 as a
neighbor ROSE (address 405732).  It will use a conventional port named
ax0.

An example of the rose add command on IP station Number 1 (k5jb) is:

        rose add k5jb-11 k5jb-5

Where the -11 call is my IP station's call and k5jb-5 is its neighbor
rose.

If you want to drop a call from the table, the command is:

        rose drop <IP station's call>

Because we normally will be able to only create a single return circuit,
you should only have one rose table entry for an IP station.  This is
not a serious limitation because you and the other IP station have to
coordinate both ends anyway and set your routes to match.

You can have a maximum of 10 IP station/ROSE call pairs in the rose
table.

This takes care of incoming packets; now to route outgoing packets.

Before we describe how to make the port use virtual circuit, we will go
through the routing commands.  You use two standard NET commands, arp
add, and route add.  For our purpose, we use a simple form of the arp
add command with the syntax:

        arp add <hostname> ax25 <AX.25 call path>

Using the calls in the example above, the arp add command would be:

        arp add k5jbspook ax25 k5jb-11 n0els-5 405732

The call sign string is the same as one you would use to make an ax25
connection manually over that ROSE circuit (destination call, neighbor
ROSE call, destination ROSE address).

For our purpose we use a simple version of the route add command with
the syntax:

        route add <hostname> <iface name>

And using the example calls, would be:

        route add k5jbspook kp0a

assuming that we are using kp0a as our asynchronous port for this
circuit.  Thus it takes three command entries for each circuit: rose
add, arp add, and route add.  (The arp add and route add commands are
unchanged for ROSE.  You can add all the sophistication you want to
them.  See the NET manual.)

Finally, if you don't use the rose attach command (described next) we
need to tell NET to use virtual circuit mode on your async port (ax0 in
this example) by using the mode command:

        mode kp0a v

To complete our example, we move to the second IP station (k5jbspook)
and use the following to reach k5jb on ROSE:

        rose add k5jb-10 k5jb-5
        arp add k5jb ax25 k5jb-10 k5jb-5 405771
        route add k5jb ax0
        mode ax0 v

Incidentally, if you are using Desqview (you should!) you can use the
transfer command to move complicated lines from your autoexec.net file
to a running net and avoid typing mistakes.  This method also organizes
your routing so you don't forget what you were doing.

If you don't want to dedicate your async interface to VC (which I
didn't) you may want to attach and try the pseudo rose interface, here
is how to do it.

The command for attaching this pseudo interface is:

        rose attach <rose iface name> <async iface name>

If you only have one async interface attached, called ax0, I suggest you
simply use the command:

        rose attach rose ax0

If you are using more than one interface, you might use "ro0", "ro1",
etc.  If you are using the Kantronics KPC-4 or KAM interface, there is a
strict naming convention you must follow.  If the interface to be used
is kp0a, use the name rosa, ro0a, or whatever, four characters long,
ending with the same letter as the end of the kpc port name.  In my IP
station example above, I would use, rose attach rosa kp0a, (Second port
would have been, rose attach rosb kp0b.)  This is necessary because of
the way the KPC-4 code handles two ports and puts "a" or "b" in that
last character's position depending on which logical port received
traffic.  For various reasons, don't use a name of more than four char-
acters long.

(DRSI PC*PA driver I implemented in NET uses the same naming convention
but this ROSE interface has not been checked against the DRSI driver yet
to see if it works.  Since we used the DRSI driver as a pattern to
handle the dual port KPC-4, it will likely work.)

You can add a maximum of 4 pseudo interfaces to 4 corresponding async
interfaces.  This maximum and the maximum number of IP station/ROSE
neighbor pairs can be changed by defines in rose.c.  If you use the
pseudo rose interface you don't have to use the mode command.

A benign disadvantage of doing it the way I did is that if you want to
trace incoming data on a port, you need to trace it by its natural
interface name and also by its pseudo rose name because incoming packets
will appear to come in on either of the interfaces depending on which
interface name is serviced first by the interface commutator loop after
a packet is received on that port.  The pseudo port preceeds the real
port in the interface chain but the real port will handle some of the
incoming packets if they are received while the pseudo port is working
on its data.

NET feeds outgoing packets to the ROSE network by looking up the host in
the arp table, getting the route from the route table, and since the
pseudo rose interface was installed as a VC, initiating an AX.25 connect
to the ROSE switch.  After some spurious packets from the ROSE switch
are read and discarded, you are in business!  (These packets are dis-
carded by the IP handler because they fail the checksum test and the
failures are duly recorded in the statistics displayed by the ip stat
command.)

If you are using NOS, there is no need for this pseudo interface.  The
standard outgoing packet routing commands you use are, ax25 route add,
and ax25 route mode.  Using the same calls as used above, an example
command on k5jb-10 to reach k5jb-11 with ROSE would be:

   ax25 route add k5jb-11 n0els-5 405732
   ax25 route mode k5jb-11 vc

These notes may not be clear enough to this point because the first two
stations that tried this scheme failed because they didn't coordinate
what they were doing with the target stations on the other ends of a ROSE
circuit.  Both ends have to set up tables and routes to match each
other.  Perhaps someday we will be able to drag a computer out of a box,
connect it to a radio, pop up on a network, and have it work without
following any rules -- but not yet!  Coordinate what you want to do with
your buddy and then have at it!

In summary:

 1. Decide what you want to do
 2. Get someone else to agree (use the AX.25 mailbox to pass messages)
 3. Use the rose add command
 4. Use the arp add command
 5. Use the route add command
 6. Either use the mode command or the rose attach command, or if
    using NOS, use the ax25 route add and ax25 route mode commands.
 7. Get the other person to set his/her station to correspond.
 8. Ping the other station.  Watch for the return.
 9. Do it again, it won't take so long for a return this time.

Now you won't have to use that AX.25 mailbox anymore to send messages to
your buddy.

Sorry about the kludge, but I had to do something!  If all the ROSE
switches suddenly start passing the PID byte, we can forget about this.
On the other hand, how does TEXNET handle IP frames?

BTW, Look at the users list on your neighbor switch after you establish
a session.  Holy Cow!  It says it doesn't know what the 0xcc PID is,
heh!  I bet it really does!

Enjoy!

Joe, K5JB